<html>
<head>
<title>Not-Yet-Commons-SSL - Downloads, Features, Future Directions</title>
<style type="text/css">
dl, h1, h2, h3, h4 { margin: 0; border: 0; padding: 0; font-size: 100%; }
h1 { float: left; color: red; }
b.n { font-family: arial; font-weight: bold; }
span.hl { color: white; background-color: green; }
div.nav { float: left; margin-left: 20px; font-weight: bold; }
.nav a, .nav span { padding: 0 5px; }
.nav a { color: blue; }
td.v { text-align: center; }
dt { padding: 8px 0 8px 5px; }
dd { padding-left: 15px; }
li { padding-bottom: 6px; }
tr.released td, tr.released th { background-color: yellow; font-weight: bold; }
</style>
</head>
<body>
<h1>not-yet-commons-ssl</h1>
<div class="nav">
<a href="index.html">main</a> |
<a href="ssl.html">ssl</a> |

<a href="pkcs8.html">pkcs8</a> |
<a href="pbe.html">pbe</a> |
<a href="rmi.html">rmi</a> |
<a href="utilities.html">utilities</a> |
<a href="source.html">source</a> |
<a href="javadocs/">javadocs</a> |

<span class="hl" href="download.html">download</span>
</div>
<br clear="all"/>
<hr/>
<h2>Download Not-Yet-Commons-SSL!</em></h2>
<p>Not-Yet-Commons-SSL currently has NO affiliation with the <a href="http://apache.org/">Apache Software Foundation</a> (apache.org), but we're hoping
to start <a href="http://incubator.apache.org/incubation/Incubation_Policy.html">Incubation</a> one day.
<table cellpadding="6" cellspacing="0" border="0" style="margin-top: 9px;">
<tr><th colspan="3">Current Version (March 16th, 2015):</th></tr>
<tr><td>Full source:</td><td><a href="/not-yet-commons-ssl-0.3.17/not-yet-commons-ssl-0.3.17.zip">not-yet-commons-ssl-0.3.17.zip</a></td><td>15 MB</td><td><span style="color: red;">Alpha</span></td><td>MD5: abbba5b3d0a67a0ff50bc9716bc5c6f8</td></tr>
<tr><td>Binary only:</td><td><a href="/not-yet-commons-ssl-0.3.17/not-yet-commons-ssl-0.3.17.jar">not-yet-commons-ssl-0.3.17.jar</a></td><td>991KB</td><td><span style="color: red;">Alpha</span></td><td>MD5: f81f13575bd317ab4d9a6e73f58d4f36</td></tr>
    <tr><th colspan="3">Previous Version (September 23rd, 2014):</th></tr>
    <tr><td>Full source:</td><td><a href="/commons-ssl/not-yet-commons-ssl-0.3.16.zip">not-yet-commons-ssl-0.3.16.zip</a></td><td>5.8MB</td><td><span style="color: red;">Alpha</span></td><td>MD5: a76a059767d3e67881da1680a32f16a8</td></tr>
    <tr><td>Binary only:</td><td><a href="/commons-ssl/not-yet-commons-ssl-0.3.16.jar">not-yet-commons-ssl-0.3.16.jar</a></td><td>267KB</td><td><span style="color: red;">Alpha</span></td><td>MD5: ac3c7c1722222970677e723c22f1d4c8</td></tr>
    <tr><th colspan="3">All Previous Versions (use "svn export"):</th></tr>
    <tr><td>&nbsp;</td><td colspan="2"><a href='http://juliusdavies.ca/svn/not-yet-commons-ssl/tags/'>/svn/not-yet-commons-ssl/tags/</a></td></tr>
</table>
<br/><b>Warning:</b>
&nbsp;<span style="color: red; font-weight: bold;">All versions of not-yet-commons-ssl should be considered to be of "Alpha" quality!
This code probably contains bugs.  This code may have security issues.</span>
<p>Future versions will definitely break the current API in a non-reverse compatible way.  After commons-ssl-0.5.0, though, we
plan on always being reverse compatible with ourselves.
<hr/>
<h3>Changelog for not-yet-commons-ssl-0.3.17:</h3>
<dl>
    <dt>1. Bug fix for using SNI names with TLS.</dt>
    <dd>We now call "setHost()" on the underlying sun.security.ssl.SSLSocketImpl
    socket class if possible to make interop with SNI-enabled servers possible.  Called via reflection to maintain backwards
    compatibility with Java 5.  (Note: SNI + TLS seems to only work on Java 7 or newer.)</dd>
    <dt>2. Update ASN1 parsing code with latest from BouncyCastle.org.</dt>
    <dd>
We've also moved all the ASN1 parsing code into a new "org.apache.commons.ssl.org.bouncycastle" namespace
to make the code provenance clear.  
<span style="color: red;">Warning:  this change could introduce regressions --- the BouncyCastle update
required we update some of our own code to accommodate changes in their API.</span>
    </dd>
</dl>

<h3>Changelog for not-yet-commons-ssl-0.3.16:</h3>
<dl>
    <dt>1. Bug fix for TrustMaterial constructor.</dt>
    <dd>Re-introduce ability to load an X509 certificate specified as raw bytes (e.g., byte[]) in the constructor.  (Thanks to Brent Putnam for the bug report).</dd></dd>
    <dt>2. Remove protocol / cipher whitelists.</dt>
    <dd>
Got rid of useStrongCiphers() method (and its converse, useDefaultCiphers()), since all ciphers in Java 7 are at least 128 bit, and my approach used a white list that was starting to get out-of-date.  If users want to ensure only strong ciphers are used in their SSL connections, they can either upgrade to Java 7 or newer, or invoke SSLClient.setEnabledCiphers() or SSLServer.setEnabledCiphers().   Also got rid of all logic that was setting default protocols, because again it was a white list that was getting out of date.  We do still call SSLContext.getInstance("TLS") by default (can be overridden), but I figure that one should be okay for at least another decade.
    </dd>
</dl>

<h3>Changelog for not-yet-commons-ssl-0.3.15:</h3>
<dl>
    <dt>1. Security patch from Redhat for CVE alert.</dt>
    <dd>The way we parse the Principal (e.g., "CN=a,OU=b,O=c") from an X509 Certificate had a serious security flaw.
    Thanks to Redhat, Arun Babu Neelicattu, and David Jorm for notifying us, and for the patch they submitted.</dd></dd>
    <dt>2. Upgrade to Java 1.5.</dt>
    <dd>Not-yet-commons-ssl now requires at least Java 1.5 to run (a.k.a. Java 5).
    If you really need Java 1.3 or Java 1.4 compatibility, please email the mailing list; it's not too late for us to
    rejig things to bring that back, but we're not going to bother unless someone actually needs it.
    </dd>
</dl>
<h3>Changelog for not-yet-commons-ssl-0.3.13:</h3>
<dl>
<dt>1. Fix bugs in AuthSSLProtocolSocketFactory and TrustSSLProtocolSocketFactory.</dt>
<dd>KeyMaterial's constructor has been checking that KeyMaterial contains at least one
private key, but this assumption was invalid with these guys.  The fall-back to the
TrustMaterial constructor if necessary.   (Wonder how long this has been broken!   Oops!)</dd>

<dt>2. Upgraded from JUnit3 to JUnit4.  Added some extra unit tests.</dt>
</dl>
<h3>Changelog for not-yet-commons-ssl-0.3.12:</h3>
<dl>
<dt>1. Avoid reverse-DNS lookups with literal IP address connections.</dt>
<dd>Based on my own investigation, InetAddress.getByAddress(String, byte[]) does not do the reverse-DNS lookup that plagues Java SSL users, so we call that whenever possible.</dd>
</dl>
<h3>Changelog for not-yet-commons-ssl-0.3.11:</h3>
<dl>
<dt>1.  Fixed KeyStoreBuilder.</dt>
<dd>It really can handle KeyStores now where the store-password and key-password differ.  It can
also now handle all the things 0.3.9 couuld handle, too.  Whoops.  Sorry about 0.3.10, everyone.</dd>

<dt>2.  KeyStoreBuilder auto-detects BouncyCastle BKS and UBER keystore types.</dt>

<dt>3.  CRL checking no longer blocks forever in bad network situations (Java 5 and newer).</dt>
<dd>CRL checking was using default java.net.URL behaviour, which unfortunately can
cause infinite blocking.  CRL checking now waits at most 5 seconds for the CRL server
to respond.  <b>Note:  Only works on Java 1.5 and above.</b></dd>

<dt>4.  Lot's more unit tests.  Especially for KeyStoreBuilder.</dt>

<dt>5.  Base64InputStream's default behaviour changed to DECODE.  VERY SORRY!</dt>

<dt>6.  PKCS8Key.getPublicKey() and PEMUtil.toPEM() methods added. </dt>
</dl>
<br/>
<h3>Features as of not-yet-commons-ssl-0.3.10:</h3>
<dl>
<dt>1. <a href="utilities.html#KSB">KeyStoreBuilder</a> broken.
<dd>
<b>Version 0.3.10 should be avoided!</b>
</dd>
</dl>

<br/>
<h3>Features as of not-yet-commons-ssl-0.3.9:</h3>
<dl>
<dt>1. <a href="pbe.html">PBE</a> is now Compatible with <code>openssl enc -K [key] -iv [IV]</code>.</dt>
<dd>People were asking for this.  See the PBE page for more details.</dd>
<dt>2. DES2 with PBE was broken.</dt>
<dd>Fixed.</dd>

<dt>3. directory.apache.org didn't write the ASN.1 code.  BouncyCastle did.</dt>
<dd>Now using latest ASN.1 parsing code from BC, and attributing it properly.</dd>
<dt>4. The "ping" utility has a few more options.</dt>
<dd>For those who need more than just a "HEAD /" request.  You can also set the HTTP host header,
independant of the target host/ip.</dd>
</dl>
<br/>
<h3>Features as of not-yet-commons-ssl-0.3.8:</h3>
<dl>
<dt>1. useDefaultJavaCiphers() actually works now.</dt>
<dd>When you want to allow 40 bit, 56 bit, and MD5 based SSL ciphers, use this.  It was 99% functional in 0.3.7, but there was a
rare situation where setting ciphers was causing SSL handshake errors.</dd>

<dt>2. <a href="pbe.html">PBE</a> (password-based-encryption) improved.</dt>
<dd>PBE now has its own <a href="pbe.html">HTML page</a>.  Support for all of OpenSSL's PBE ciphers implemented and tested, including
IDEA and RC5.  (DES-X might work, but couldn't find a JCE provider that supported it).  Threw in support for some
additional BouncyCastle ciphers even though OpenSSL doesn't support them (cast6, gost28147, rc6, seed, serpent,
skipjack, tea, twofish, xtea).  Around <a href="samples/pbe/">650 test files</a> created to make sure PBE is working properly.
</dd>
<dt>3. PBE API changed on <a href="javadocs/org/apache/commons/ssl/OpenSSL.html#encrypt(java.lang.String,%20char[],%20java.io.InputStream)">OpenSSL.encrypt()</a> and <a href="javadocs/org/apache/commons/ssl/OpenSSL.html#decrypt(java.lang.String,%20char[],%20java.io.InputStream)">OpenSSL.decrypt()</a>.</dt>

<dd>The password is now char[] instead of byte[] (sorry!).  Encrypt/decrypt on byte[] introduced.  Encrypt/decrypt on InputStream
is still available, and is properly streamed so that even extremely large files can be encrypted/decrypted.</dd>
</dl>
<br/>
<h3>Features as of not-yet-commons-ssl-0.3.7:</h3>
<dl>
<dt>1. useStrongCiphers() used by default.</dt>
<dd>40 bit and 56 bit ciphers are now disabled by default.  To turn them back on call useDefaultJavaCiphers().</dd>
<dt>2. addAllowedName() adds some flexibility to the CN verification.</dt>
<dd>
Here's a code example using "cucbc.com" to connect, but anticipating "www.cucbc.com" in the server's certificate:
<pre>
SSLClient client = new SSLClient();
client.addAllowedName( "www.cucbc.com" );
Socket s = client.createSocket( "cucbc.com", 443 );

</pre>
This technique is also useful if you don't want to use DNS, and want to
connect using the IP address.
</dd>
<dt>3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat.</dt>
<dd>
<pre>
SSLClient server = new SSLServer();
server.useTomcatSSLMaterial();
</pre>
</dd>
<dt>4. RMI-SSL support improved.</dt>
<dd>Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets.
Anonymous server-sockets (port 0) will always be set to port 31099.  Analyzes the
server certificate CN field and tries to set "java.rmi.server.hostname" to something
compatible with that.  Probably the only free implementation around that does a good
job on the hostname verification!
</dd>
<dt>5. KeyMaterial constructor blows up earlier.</dt>
<dd>If a JKS or PKCS12 file is provided that isn't going to work (e.g. no private keys),
the KeyMaterial constructor throws an exception right away.</dd>

<dt>6. getSSLContext() now available to help inter-op with Java 5 SSL-NIO libraries.</dt>
<dd>Oleg has been working hard on SSL-NIO for the Apache httpcomponents library.  Go
check it out!</dd>
<dt>7. Fixed bug where SSLClient couldn't be used with javax.net.ssl.HttpsURLConnection
on Java 1.4.x</dt>
<dd>I was wrapping the SSLSocket, but Java 1.4.x guards against that inside HttpsURLConnection
and throws this exciting exception:
<pre>
java.lang.RuntimeException: Export restriction: this JSSE implementation is non-pluggable.
  at com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.checkCreate(DashoA6275)
  at sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275)
  at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(DashoA6275)
  at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:560)
  at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(DashoA6275)
</pre>
Silly Java - I'm still using <em>your</em> JSSE implementation, I'm just wrapping it!
</dd>
</dl>
<br/>

<h3>Features as of not-yet-commons-ssl-0.3.4:</h3>
<dl>
<dt>1. &nbsp;<code>"javax.net.ssl.keyStore"</code> and <code>"javax.net.ssl.trustStore"</code></dt>
<dd>SSLClient and SSLServer now set their default TrustMaterial and KeyMaterial from these
 system properties if they are present.</dd>
<dt>2. &nbsp;<code>ssl.setCheckCRL( true/false )</code> <em>Note: <a href="http://en.wikipedia.org/wiki/Certificate_revocation_list">CRL</a> is an abbreviation for "Certificate Revocation List"</em></dt>

<dd>Set to <code>true</code> by default.  If you're using SSLClient, then the remote
server's certificate chain is checked.  If you're using SSLServer, CRL checking is ignored <em>unless</em>
client certificates are presented.  Commons-SSL tries to perform the CRL check against each certificate in
the chain, but we're not sure if we always know the entire chain.
<p><em>Implementation note:</em>
To reduce memory consumption all CRL's are saved to disk using
<code>File.createTempFile()</code> and <code>File.deleteOnExit()</code>.
CRL's are re-downloaded every 24 hours.  To reduce disk IO
the "pass/fail" result of a CRL check for a given X.509 Certificate is cached using the 20 byte SHA1 hash of the
certificate as the key.  The cached "pass" result is discarded every 24 hours.  The cached "fail" result is retained 
until the JVM restarts.
</p>
</dd>

<dt>3. &nbsp;<code>ssl.setCheckExpiry( true/false )</code></dt>
<dd>Certificate expiry checking can be turned off.  Turned on by default.  For Java 1.4 and newer we're
intercepting the CertificateException thrown by the TrustManager.  But we still implemented our own
expiry checking because Java 1.3 doesn't check expiry.  We check every certificate in
the chain, but we're not sure if we always know the entire chain.</dd>
<dt>4. &nbsp;<code>ssl.setCheckHostname( true/false )</code></dt>
<dd>Certificate hostname checking improved.  Turned on by default for SSLClient, but turned off by
default for SSLServer.  If turned on for SSLServer, only applied to client certificates by checking
against a reverse DNS lookup of the client's IP address.  Turning on for SSLServer will probably be
quite rare.  We imagine that applications (such as Tomcat) will pass the client chain back up into
the business layer where people can code in any kind of validation logic they like.  But we put
it in anyway to keep things consistent.
<p>Support added for certificates with wildcards in the CN field 
(e.g. <a href="https://www.credential.com/">*.credential.com</a>). 
Java already had this, to be fair.  We broke it
by accident!
<pre style="font-style: 90%; padding: 0 30px;">
s: CN=*.credential.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/cps (c)05,
   OU=businessprofile.geotrust.com/get.jsp?GT27402892, O=*.credential.com, C=CA
i: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
</pre>
</p>
</dd>

<dt>5. &nbsp;PKCS8 support.</dt>
<dd>Support for OpenSSL "Traditional" and PKCS8 encrypted private keys added.
Private keys can be RSA or DSA.  See our <a href="pkcs8.html">pkcs8 page</a> for more details.</dt>
<dt>6. &nbsp;New Utility: "<code>KeyStoreBuilder</code>"</dt>
<dd>Command line utility converts an OpenSSL pair (private key + certificate) into a Java Keystore ("JKS")
file.  To see the command-line options, visit our <a href="utilities.html">utilities page</a>, or just run:
<pre style="font-style: 90%; padding: 0 30px;">

java -cp commons-ssl-0.3.4.jar org.apache.commons.ssl.KeyStoreBuilder
</pre></dd>
</dl>

</body>
</html>
